In a large, distributed computer system connected by a network, management personnel and resources typically manage the system from a system console using a command line interface (CLI) or a graphic user interface (GUI). These interfaces directly, or indirectly, control various data management services, such as data replication, imaging, caching and remote notification services. In order to control these services the CLI or GUI must discover which data management services, or combination of services are running in a particular host system and which host systems in a distributed computer system have data management services installed and running. In a small simple network, the location process is also relatively simple, however, in large distributed systems, where there are many clients and data services, the lookup process becomes much more complex.
One prior art method of dealing with this lookup problem is called Jini™ Network Technology, which is available from Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, Calif. 94303 (Jini is a trademark of Sun Microsystems, Inc.) Jini™ technology consists of an infrastructure and a programming model that allow clients to find and interconnect with services in a distributed network. Network services run on top of the Jini software architecture and are located by means of “lookup” services that reside on lookup servers.
A lookup service provides a central registry of services available within a service group of clients and services that are operating with the Jini™ architecture. Each lookup service maintains a flat collection of service items, where each service item represents an instance of a service available within the service group. The item contains a remote invocation stub (if the service is implemented as a remote object) or other object (if the service makes use of a local proxy) that programs use to access the service, and an extensible collection of attributes that describe the service or provide secondary interfaces to the service.
When a new service is created (for example, when a new device is added to the service group), the service registers itself with a lookup service associated with the group, providing a service item with an initial collection of attributes. For example, a printer might include attributes indicating speed (in pages per minute), resolution (in dots per inch), and whether duplex printing is supported. Among the attributes might be an indicator that the service is new and needs to be configured.
The lookup service also has an event service and clients can register an interest in the occurrence of selected events with the event service in a conventional manner. In particular, when services join or leave a lookup service, events are signaled, and clients that have registered an interest in such events get notifications when new services become available or old services cease to be active.
The service attributes can be used in different manners. For example, an administrator might use the event mechanism provided by the lookup service to receive notifications as new services are registered. To configure these new services, the administrator might look for an attribute that provides an applet for this purpose. The administrator might also use an applet to add new attributes, such as the physical location of the service and a common name for it; the service would receive these attribute change requests from the applet and respond by making the changes at the lookup service.
When the aforementioned CLI or GUI programs need to control a particular data service, they can use the Jini™ lookup service to find an instance of that data service. A client program finds services by looking for a service item with attributes that match an attribute specification through a process called “discovery.”
The discovery process begins when a client attempts to obtain references to one or more lookup services. Specifically, the client issues a multicast that requests references to nearby lookup services. Any lookup services that receive the request connect to the client response server and provide service ID references to themselves.
Once service IDs to the lookup services have been obtained, a client can look for a matching service item. An attribute match can be made based on the specific data types for the Java™ programming language implemented by the service as well as the specific attributes attached to the service. Although the collection of service items in a lookup service is flat, a variety of hierarchical views can be imposed on the collection by aggregating items according to service types and attributes. The lookup service provides a set of methods to enable incremental exploration of the collection. When an appropriate service is found, the client can download any code it needs in order to talk to the service, thereby learning how to talk to the service implementation via the service API.
The Jini™ lookup service performs well, however, the lookup processing is complex and time consuming. If the lookup process must be used to locate a particular data management service each time a CLI or GUI for that particular service is invoked, the performance of the data management service is reduced.
Therefore, there is a need to provide a simple, fast way to discover data management services on hosts, both local and remote and to reduce the time needed to make such a lookup.